The Universal Mobile Telecommunications System (UMTS) is a third generation wireless system designed to provide higher data rates and enhanced services to subscribers. The UMTS architecture includes a subsystem known as the IP Multimedia Subsystem (IMS) for supporting traditional telephony as well as new IP multimedia services (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Releases 5 to 7). IMS provides key features to enrich the end-user person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks. The IMS is able to connect to both PSTN/ISDN (Public Switched Telephone Network/Integrated Services Digital Network) as well as the Internet. FIG. 1 illustrates schematically this functionality, where components of the IMS core are interconnected with, by way of example, a PSTN network, a legacy mobile signalling network such as a GSM/GPRS network, and of course IP Multimedia networks such as a 3G network.
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). SIP makes it possible for a calling party to establish a packet switched session to a called party (using so-called SIP User Agents, UAs, installed in the user terminals) even though the calling party does not know the current IP address of the called party prior to initiating the call. The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly. The 3GPP has chosen SIP for signalling between a User Equipment (UE) and the IMS as well as between the components within the IMS.
Specific details of the operation of the UMTS communications network and of the various components within such a network can be found from the Technical Specifications for UMTS that are available from http://www.3gpp.org. Further details of the use of SIP within UMTS can be found from the 3GPP Technical Specification TS 24.228 V5.8.0 (2004-03).
Referring again to FIG. 1, the IMS core comprises Call/Session Control Functions (CSCFs) that operate as SIP proxies within the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
3GPP specifications mandate that every IMS core network subsystem subscriber shall have one or more Private User Identities (IMPI). An IMPI is assigned by the subscriber's home network operator, and is used for IMS registration (i.e. for authorization and authentication purposes). This identity shall take the form of a Network Access Identifier (NAI) as defined in RFC 2486. It should be noted that a subscription may be attached to a person or to an organisation such as a corporation. Nonetheless, in the following discussion the term “user” is used synonymously with the term “Private User Identity”.
A user (Private User Identity) may have one or more Public User Identities. The Public User Identity/Identities (IMPU) are used by any user for requesting communications to other users (in the form of SIP URI—IETF RFC 3261 [26]—or a TEL URL—IETF RFC 3966). The relationship between IMPUs and IMPIs is defined by 3GPP Rel-6 onwards and is illustrated schematically in FIG. 2. It is apparent that IMPUs may be shared across multiple IMPIs within the same IMS subscription. Consider a family having a single IMS subscription, with each member of the family being allocated their own IMPI. As well as having their own, personal IMPUs, the family members may share a family IMPU to allow all the members to receive incoming IMS calls directed to the family IMPU.
A user registers a contact address for an IMPU with the IMS core network, using the SIP Register method. As well as registering a contact address for the IMPU identified in the Register message, the same contact address is registered for any other IMPUs belonging to the same “Implicit Registration Set” (IRS). The IRS construct is also illustrated in FIG. 2.
Returning to the subject of IMS registration, the general IMS registration process is illustrated in the signalling flow of FIG. 3 for a User Equipment (UE) comprising an IMS client. The main steps are as follows:                1. The UE sends the Register information flow to the P-CSCF (the Register including the IMPU to be registered, IMPI, home network domain name, and UE IP address).        2. The P-CSCF shall examine the “home domain name” to discover the entry point to the home network (i.e. the I-CSCF). The proxy shall send the Register information flow to the I-CSCF (including the P-CSCF address/name, IMPU, IMPI, P-CSCF network identifier, and UE IP address).        3. The I-CSCF shall send the Cx-Query/Cx-Select-Pull information flow to the HSS (including IMPU, IMPI, P-CSCF network identifier). The HSS shall check whether the user is registered already. The HSS shall indicate whether the user is allowed to register in that P-CSCF network (identified by the P-CSCF network identifier) according to the User subscription and operator limitations/restrictions if any. The HSS performs authorization checks based on the IMPI/IMPU pair. Note that it is mandatory that both the IMPI and IMPU identities are present in the received message.        4. A Cx-Query Resp/Cx-Select-Pull Resp is sent from the HSS to the I-CSCF. It shall contain the S-CSCF name if it is known by the HSS, or the S-CSCF capabilities if it is necessary for the I-CSCF to select a new S-CSCF.        5. The I-CSCF shall send the register information flow (including P-CSCF address/name, IMPU, IMPI, P-CSCF network identifier, UE IP address, and the I-CSCF(THIG) in case network configuration hiding is desired) to the already allocated or selected S-CSCF.         Although not indicated in the flow, 3GPP specifies in another specification (33.210) that, at this point, the S-CSCF initiates authentication procedures for the received IMPU-IMPI pair by sending a Cx-Auth command to the HSS. It is mandatory for authentication purposes to include the IMPI in the Cx interface at this point. Otherwise authentication will fail.        6. Following a successful authentication, the S-CSCF shall send Cx-Put/Cx-Pull (IMPU, IMPI, S-CSCF name) to the HSS.        7. The HSS shall store the S-CSCF name for that user (IMPI) and return the information flow Cx-Put Resp/Cx-Pull Resp (user profile) to the S-CSCF.        8. Based on the user profile, the S-CSCF shall perform whatever service control procedures are appropriate. The S-CSCF will also record the contact address for the registered IMPU (and for any other IMPUs within the same IRS).        9. The S-CSCF shall return the 200 OK information flow (home network contact information) to the I-CSCF.        10. The I-CSCF shall send information flow 200 OK (home network contact information) to the P-CSCF. The I-CSCF shall release all registration information after sending information flow 200 OK.        11. The P-CSCF shall store the home network contact information, and shall send information flow 200 OK to the UE.        
It is clear that for the registration process to succeed, the HSS must receive the IMPI/IMPU pair so that it can perform authentication, check if the user is already registered, and apply operator limitations/restrictions if any. This is of course not a problem for user terminals that are provisioned with an IMS Subscriber Identity Module (ISIM) and within which are recorded the appropriate IMPI and IMPU(s), or terminals that are provisioned with a USIM that is capable of generating an IMPI and IMPU from an International Mobile Subscriber Identity (IMSI).
Fixed-Mobile Convergence (FMC) is being demanded by network operators. In the context of IMS, FMC means the convergence of mobile and fixed access to the IMS system. Operators are working on scenarios that allow the same subscriber to access IMS services using different technologies. This means that the subscriber may sometimes access the IMS network via a fixed access and at other times via a mobile access. Considering the example of FIG. 4, this may give rise to the situation where IMPI1 is registered with IMPU2 via a Fixed access, and IMPI2 is registered with same IMPU2 via a Mobile access.
Legacy terminals of the type used for fixed access (and in some cases for mobile access), although including a SIP client provisioned with an IMPU, do not contain an IMPI or are not otherwise able to generate an IMPI for themselves. To allow for this, the inclusion of the Authorisation header in the Register with username field set to the value of the IMPI, is optional (see 3GPP TS 24.229 section 5.1.1.2.5—Initial registration using NASS-IMS bundled authentication). Furthermore, a mechanism known as “Early IMS” has been specified (3GPP TS 33.978) to allow a user terminal without access to an IMPI to register with the IMS. In order to satisfy the requirement that the HSS must receive the IMPI in the Cx messages from the I-CSCF and the S-CSCF, TS 33.978 provides for the I-CSCF to derive an IMPI from the provided IMPU. In particular, chapter 6.2.5.1 states:                “the Private User Identity (User-Name AVP) in the UAR command shall be derived from the temporary Public User Identity URI being registered by removing URI scheme and the following parts of the URI if present port number, URI parameters, and headers.”        
The derived IMPU is however most likely disregarded by the HSS, with the HSS using the IMPU to obtain the provisioned IMPI for the purpose of checking if the user is already registered and applying operator limitations/restrictions. However, this effectively precludes IMPU sharing in the context of FMC as otherwise the IMS network would be unable to map the received IMPU to the correct IMPI (i.e. in the absence of the correct IMPI from the Register message).
As the IMS is, too a large extent, blind to access type, this inability on the part of legacy terminals to provide an IMPI prevents implementation of IMPU sharing.